1. Field
The disclosed aspects relate generally to communications between devices and specifically to methods and systems for improving mechanisms for managing logical connection establishment between a Near Field Communication (NFC) controller (NFCC) and a device host (DH).
2. Background
Advances in technology have resulted in smaller and more powerful personal computing devices. For example, there currently exist a variety of portable personal computing devices, including wireless computing devices, such as portable wireless telephones, personal digital assistants (PDAs) and paging devices that are each small, lightweight, and can be easily carried by users. More specifically, the portable wireless telephones, for example, further include cellular telephones that communicate voice and data packets over wireless networks. Many such cellular telephones are manufactured with ever increasing computing capabilities, and as such, are becoming tantamount to small personal computers and hand-held PDAs. Further, such devices are enabling communications using a variety of frequencies and applicable coverage areas, such as cellular communications, wireless local area network (WLAN) communications, NFC, etc.
When the NFCC is initially activated to communicate with the DH a static radio frequency (RF) connection is established as part of the process. Currently, the NFCC responds to a core initialization command (CORE_INIT_CMD) from the DH with a core initialization response (CORE_INIT_RSP) indicating, among other elements, a maximum data packet payload size and an initial number of credits, and assigning a connection identifier (ID) (ConnID) with a fixed value of zero. This exchange of messages occurs prior to the NFCC detecting any remote NFC endpoint, and as such, prior to the NFCC possessing any knowledge relating to potential future RF connection requirements. In other words, under current specifications, during initialization the NFCC defines not just the amount of memory allocated to the static RF connection (e.g., logical connection) with ConnID=0, but both the width (payload size) and the depth (credits) of the buffer, without any information about the nature of the data that may pass through this connection. The NFCC may not become aware of which RF protocol and/or RF interface to be used for data communication until after a remote NFC endpoint is detected. For example, if the NFCC detects a Type 2 Tag, the NFCC may allocate multiple buffers of 16 byte packets for the simple READ/WRITE commands, whereas if the NFCC detects a Type 4 Tag, the NFCC may allocate comparatively fewer 256 byte packets for application protocol data unit (APDU) exchange.
Further, current NFC specifications impose a requirement on the NFCC to allocate data buffer memory for Connection ID 0 without any information about a remote NFC endpoint that may use it, and then imposes a requirement on the DH not to use the logical connection until the RF Interface is activated. Yet further, once the buffer memory is allocated, the current NFC specification does not provide any way to resize this buffer memory based on subsequent information about RF Protocol or RF Interface, etc. Moreover, performance for any dynamic logical connections subsequently established may be compromised because there is no way to free the buffer memory for Connection ID 0.
Thus, improved apparatuses and methods for providing mechanisms for managing logical connection initialization and buffer allocation may be desired.